Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.
Мы уже весьма немало писали про возможности обновленной версии платформы виртуализации VMware vSphere 6, в которой будет настолько много новых фичей, что мы не можем перечислить их все в одной статье. Поэтому мы делаем это по частям:
В этой части мы расскажем о новых возможностях платформы vSphere с точки зрения улучшений, сделанных непосредственно в плане хостов ESXi и виртуальных машин.
Итак, начнем по порядку:
1. Новые возможности хост-сервера и кластера.
Если еще с давних времен кластеры VMware HA/DRS объединяли 32 хоста, то в версии vSphere 6 кластер, наконец-то, может объединять до 64 хостов включительно. Помимо этого, на хосте может быть запущено до 1000 виртуальных машин (и до 8000 в кластере), а сам ESXi поддерживает сервер с числом процессоров до 480 CPU и памятью до 12 ТБ.
Сравним с предыдущей версией:
2. Новые возможности виртуальных машин.
Виртуальные машины, как и хосты ESXi, также стали поддерживать еще большие максимальные конфигурации - теперь можно создать машину со 128 vCPU и до 12 ТБ оперативной памяти:
Интересны также и другие возможности. Горячее добавление памяти теперь правильно работает с vNUMA, что положительно сказывается на производительности. Появилась поддержка ускорения для объектов GDI в пакете драйверов WDDM 1.1, также контроллер xHCI 1.0 теперь работает с драйвером этого контроллера под Мак, начиная с OS X 10.8.
3. vMotion теперь работает между разными vCenter и на большие расстояния.
В VMware vSphere 6 технология горячей миграции виртуальных машин vMotion была значительно улучшена. Во-первых, виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed vSwitch в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.
Во-вторых, теперь виртуальные машины могут перемещаться между датацентрами с разными серверами vCenter (требуется лишь соединение на уровне L2). При переезде адрес виртуальной машины сохраняется и нарушения функционирования сети не происходит. Настройки машины также уезжают вместе с ней:
MAC-адреса всегда будут уникальными даже на разных vCenter, а когда машина приедет обратно - ее адрес не будет занят.
При этом для миграции не требуется ни общего хранилища, ни той же самой сети или того же vCenter - можно все это в рамках одной операции vMotion поменять:
Кроме того, если раньше vMotion "держала" задержку в канале (RTT) до 10 мс (и до 50 мс в Enterprise Plus издании), то теперь это значение увеличено до 100 мс. То есть, стратегия Follow the sun для перераспределения нагрузки - теперь реальность, так как такое RTT позволяет уже "трансконтинентальные" миграции vMotion:
Интересно, что с помощью такого vMotion можно, например, увести машины из датацентра в местности, где начинается ураган, который все обесточит - и при этом все это будет незаметно для пользователей (почти).
4. Полезные мелочи.
Во-первых, появилась настройка политики сложности пароля в Host Advanced System
Settings. Раньше для этого нужно было мудохаться с pam.d модулем.
Во-вторых, в логах хостов ESXi действия, произведенные через vCenter, включают в себя пользователя, которых их выполнял. Если раньше в логе было так: [user=vpxuser], то теперь вот так: [user=vpxuser:DOMAIN\User]. Весьма удобно.
Улучшенный механизм vSphere Network I/O Control версии 3 позволяет гарантировать уровень обслуживания на уровне vNIC виртуальной машины. Применять NetIOC можно также и к Distributed Port Group:
На этом вкратце все. Ну и так для общей информации - улучшения режима Linked Mode для серверов vCenter:
Продолжаем знакомить наших читателей с новыми возможностями платформы виртуализации VMware vSphere 6, релиз которой должен состояться уже совсем скоро. Напомним наши предыдущие посты на эту тему:
Сегодня у нас на очереди VMware vSphere 6 Web Client. Главная новость как раз об отсутствии нового - веб-клиент, по-прежнему, работает на Flash, никакого HTML5 - и это досадно. Поэтому в комментариях и пишут, что новый клиент - это "lipstick on a pig", то есть косметические улучшения без переработки по существу.
Но есть и хорошая новость - VMware уверяет, что новый клиент работает в пять раз быстрее прошлого:
Посмотрим на тесты:
Действительно, в каких-то отдельных случаях работает в 5 и более раз быстрее. Ну ок, давайте пройдемся по новым фичам:
1. Контроль производительности раздела "All Users’ Tasks".
Если раньше эта штука в панели Recent Tasks грузилась очень долго, особенно в инфраструктурах, где сервер vCenter обслуживал много хостов ESXi и пользователей, то теперь она отключена по умолчанию, чтобы не создавать нагрузки. Включить ее можно вручную, в следующем файле на сервере vCenter:
Для vCenter Server Appliance используйте этот конфиг-файл:
/etc/vmware/vsphere-client/webclient.properties
Меняем строчку show.allusers.tasks=false на show.allusers.tasks=true (перезагрузка не требуется).
Теперь все таски пользователей будут показываться в разделе All Users’ Tasks.
2. Множество улучшений производительности.
Производительность была целью номер один в новой версии vSphere 6 Web Client. Были переработаны следующие разделы:
Страницы Login (в 13 раз быстрее!) и Home
Страницы Summary
Страницы Networking
Списки Related Objects
Общая навигация по разделам
Графики производительности (Performance Charts - в 2 раза быстрее)
Контекстные меню действий по правой кнопке (Action Menu - в 4 раза быстрее!)
3. Таски и гибкое размещение панелей.
Теперь список задач удобно размещен внизу:
Сами панельки можно отлеплять и ресайзить:
4. Реорганизованные Action Menu.
Теперь в меню, вызываемых по правой кнопке, все действия размещены на нужных и интуитивно понятных местах, а сами действия не тянут при прорисовке лишних данных, что увеличивает производительность клиента:
5. Новое меню по кнопке Home.
Теперь из него можно попасть в наиболее часто используемые разделы:
6. Возможность убрать предупреждение о включенном SSH прямо из GUI.
Появилась так давно нужная ссылка Suppress Warning:
7. Возможность поместить алармы и таски на правую панель.
Очень удобно:
8. Ну и гора всяких мелочей.
Типа совместимости с прошлой и новой версией Fault Tolerance:
Самое обидное, что Web Client, по-прежнему, несовместим с VMware Update Manager - можно просматривать его задачи, но запускать Remediate нельзя.
Ну и напоследок полезная ссылка про трюки в vSphere Web Client, вам может оказаться очень полезной - http://tiny.cc/webclientwiki.
Все из вас знают, что недавно компания VMware анонсировала обновленную версию платформы VMware vSphere 6. Ввиду того, что новых функций уж очень много, мы решили разбить описание новых возможностей продуктов серверной линейки на несколько постов. Напомним последние из них:
Сегодня мы поговорим об анонсированной новой версии VMware vSphere Data Protection 6.0 (VDP) - продукте для резервного копирования виртуальных машин на серверах ESXi. Если ранее пользователям предлагалось одно из двух изданий - встроенное в платформу и vSphere Data Protection Advanced (с расширенными функциями), то теперь осталось только одно. Теперь VDP включено во все издания VMware vSphere, кроме самого базового (Essentials). То есть, пользователи vSphere 6.0 Essentials Plus и более старших изданий получат VDP в комплекте. Кстати, продукт vSphere Data Protection Advanced будет недоступен для заказа с 1 марта.
Напомним, что VDP построен на базе решения для резервного копирования и дедупликации EMC Avamar, которое развертывается как готовый виртуальный модуль (Virtual Appliance). ПО работает без агентов, использует функциональность Changed Block Tracking и может восстанавливать не только машины целиком, но и отдельные файлы из бэкапов через браузер. Шестая версия VDP поддерживает до 8 ТБ дедуплицированных данных бэкапов.
Итак, что нового появилось в VDP:
1. Агенты для Microsoft SQL Server, Exchange и SharePoint.
Напомним, что это намного раньше появилось в Veeam Backup and Replication, а теперь VMware "заимствует" функциональность у Veeam. Эти агенты позволяют создавать консистентные копии виртуальных машин с данными приложениями, а также восстанавливать отдельные объекты приложений из бэкапов (например, базу данных или электронное письмо). Агенты поддерживают такие функции, как SQL Server Failover, кластеры AlwaysOn и Exchange Database Availability Groups.
2. В VDP появилась интеграция с хранилищем EMC Data Domain с использованием ПО Data Domain Boost.
Теперь за обработку бэкапов может отвечать Data Domain, а модуль VDP просто отвечать за передачу данных. Данная функция также есть у Veeam.
3. Возможность репликации данных между модулями VDP.
Данные, передаваемые между модулями VDP дедуплицируются, поэтому в канал передаются только уникальные блоки данных. Это может оказаться необходимым при отбрасывании резервных копий на резервные хранилища через WAN. При этом поддерживаются различные топологии репликации данных виртуальных модулей - 1:1, N:1 и 1:N.
4. Сжатие данных для vSphere Replication.
Теперь если вы используете VMware SRM для репликации данных между площадками и восстановления машин после сбоев, то при передаче данных включается технология сжатия данных при передаче (end-to-end network compression).
Типичный коэффициент сжатия данных - от 1.6:1 до 1.8:1. Например, если раньше машина размером 37.5 ГБ передавалась за 52 минуты, то теперь она ужимается до 20.2 ГБ и передается за 29 минут.
5. Улучшенная репликация.
Теперь неаллоцированные регионы данных не гоняются по каналу репликации, что увеличивает ее скорость. Поддерживаются тонкие диски и устройства Virtual SAN.
6. Верификация резервных копий.
Теперь резервные копии VDP можно восстановить на временное хранилище и запустить машины отключенными от сети, чтобы убедиться, что ОС запускается и приложения работают.
7. Поддержка "подмораживания" файловых систем Linux.
Для Windows-систем уже давно есть quiescence-скрипты, которые подмораживают операции с данными ВМ, для которой происходит резервное копирование. Для Linux это появилось в версии VDP 6.0 (функция отключена по умолчанию).
8. Поддержка Storage vMotion и Storage DRS в целевом хранилище.
Ранее при перемещении реплики средствами Storage vMotion требовалась полная ресинхронизация ВМ, а в версии VDP 6.0 перемещение машин между серверами и хранилищами отслеживается, и процесс полной синхронизации не запускается.
Больше подробностей о возможностях vSphere Data Protection 6.0 можно узнать из вот этого документа.
Новые лабораторные работы по VMware vSphere 6 - попробуйте новую версию платформы без установки.
Как почти все из вас знают, компания VMware совсем недавно анонсировала новую версию платформы виртуализации VMware vSphere 6 и другие продукты серверной линейки (наша последняя статья об этом тут). Пока сам продукт недоступен для загрузки в релизной версии, но компания VMware на днях предоставила возможность попробовать его вживую в виде лабораторных работ - VMware Hands-On Labs (HoL).
В рамках лабы вам развертывают виртуальную машину, с которой вы работаете прямо в браузере:
На данный момент доступно 4 новых лабораторных работы:
Эта лаба вводит начинающих в суть темы отказоустойчивых кластеров Virtual SAN и позволяет понять основные преимущества технологии на практике, никакого булшита. Модули лабы:
Virtual SAN Setup and Enable
Virtual SAN with vMotion, Storage vMotion and HA Interoperability
В этой небольшой лабораторной работе вам расскажут про технологию EVO:RAIL, которая представляет собой стандартизованный строительный блок виртуальной инфраструктуры для небольших компаний. С технической точки зрения EVO:RAIL - это двухюнитовый блок, представляющий собой 4-узловую структуру на базе архитектуры "microserver", которая сочетает в себе 4 полноценных микросервера в 2-юнитовой корзине.
Эта лабораторная работа, посвященная возможным вариантам применения VMware Horizon 6, была доступна и ранее. Но теперь в нее добавили модуль о технологии AppVolumes, про которую мы писали вот тут (ранее это называлось CloudVolumes).
Модули лабораторной работы:
Build and Operate the Mobile Secure Workplace
Build and Operate the Call Center Desktop
Build and Operate the Branch Office Desktop
Take a Guided Tour of vCOPS for View
Understanding use cases for Application Remoting
Understanding use cases for Cloud Pod Architecture
Mirage-Controlled View Static Desktops
Guided Tour of AppVolumes
Время на прохождение: 5-8 часов (то есть на всю лабу лучше выделить целый день).
В течение пары недель компания VMware обещает выложить еще несколько лабораторных работ, посвященных VMware vSphere 6 и другим продуктам и технологиям обновленной серверной линейки, о которых мы вам обязательно расскажем. Можно также следить за обновлениями в твиттер-аккаунте VMware HoL.
Совсем недавно компания VMware анонсировала новую версию платформы виртуализации VMware vSphere 6.0, а также обновленные версии продуктов своей серверной линейки. Напомним наши статьи об этом:
Вместе с vSphere 6.0 было также объявлено и об обновлении до версии 6.0 виртуального модуля VMware vCenter Server Appliance (vCSA), построенного на базе ОС Suse Linux (SLES 11 SP3), в котором соответствующим образом настроены параметры безопасности и необходимые сервисы vCenter.
Кстати, напомним наши статьи о vCenter Server Appliance:
Ну а ниже мы расскажем, что нового появилось в vCSA 6.0.
1. Новая установка.
Теперь для развертывания vCSA понадобится ISO-образ, который можно загрузить прямо из веб-клиента vSphere:
Сам виртуальный модуль развертывается из OVF-пакета, также потребуется установить Client Integration Plug-in.
2. Типы развертывания.
С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.
На картинке ниже Platform Services Controller может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один выделенный PSC (этот режим называется External PSC).
Помимо обычной установки из GUI с помощью мастера, vCSA можно развернуть в режиме скриптовой установки. Для этого в папке vCSA-CLI-Installer есть пять различных файлов сценариев, которые подходят под различные варианты развертывания.
4. "Размер" модуля.
При развертывании теперь просят указать "размер" виртуального модуля (один из четырех видов), от которого зависит его конфигурация и максимальное число хостов и ВМ:
5. Поддержка большинства функций vCenter для Windows.
Теперь vCSA больше похож на обычный vCenter Server для Windows. Действительно, посмотрите на таблицу:
Также vCSA поддерживает следующие возможности:
Полная поддержка Hardware version 11.
Встроенная и настроенная СУБД vPostgres (в качестве внешней базы также поддерживается Oracle).
Нативная репликация вместо Microsoft ADAM.
Репликация политик и тэгов в Linked Mode.
Возможность накатывания обновлений (Product & Security) через Patch Portal.
Что не поддерживается:
Не реализована поддержка VMware Update Manager (по прежнему, надо ставить на винду).
Нет поддержки Microsoft SQL Server.
Нет средств миграции SQL Server на vPostgres.
6. Три способа доступа к консоли виртуального модуля.
Теперь получить доступ к vCSA можно тремя способами:
Обычный, через vSphere Web Client.
Доступ через Appliance Shell - в этом режиме мы переходим в консоль по SSH или через интерфейс DCUI при нажатии Alt+F1.
Через DCUI - в DCUI можно получить доступ прямо из Web Client на вкладке Summary (тадо нажать на само изображение консоли).
Прямой доступ по порту через веб-браузер больше не поддерживается.
Вот тут можно посмотреть на весь процесс установки vCSA. Кстати, говорят загружается виртуальный модуль со всеми поднятыми сервисами достаточно долго - около 8 минут.
Как вы знаете, недавно компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, и мы уже писали о технологии непрерывной доступности VMware Fault Tolerance 6.0.
Сегодня мы хотим рассказать об отказоустойчивых кластерах VMware Virtual SAN 6.0, для которых версия программного обеспечения продвинулась с 1.0 сразу до 6.0 (поэтому пользователи, все же, не должны заблуждаться насчет зрелости продукта - это его вторая версия).
Итак, что нового появилось в VMware Virtual SAN 6.0:
1. Поддержка архитектуры All Flash для создания кластера хранилищ.
Теперь доступны два варианта развертывания VSAN:
Hybrid – Virtual SAN, как и раньше, использует SSD-диски для кэширования, а для хранения ВМ используются обычные HDD-диски. Максимально возможные конфигурации этой архитектуры стали выше (например, стало 64 хоста в кластере).
All Flash – Virtual SAN использует имеющиеся Flash-накопители как для кэширования, так для хранения ВМ.
Отличия между данными архитектурами:
В конфигурации All Flash девайсы, ответственные за кэширование, будут производить только кэширование записи и не будут делать кэширование на чтение (это очевидно почему). В гибридной конфигурации, как и раньше, 30% емкости SSD-кэшей используется для Write Buffer, а 70% - для кэша на чтение.
В целом, утверждается, что решение Virtual SAN теперь готово к полноценной промышленной эксплуатации.
2. Возможность High Density Direct Attached Storage(HDDAS).
Теперь кластеры Virtual SAN удобно использовать в окружениях с блейд-системами. Для них поддерживаются как SDD, так и HDD-устройства, включая flash-хранилища блейд-серверов.
Если раньше блейд-системы не очень подходили для организации кластеров ввиду физических ограничений по локальным хранилищам, то теперь это вполне подходящий вариант использования для корпоративной инфраструктуры. Поддержка устройств будет строго контролироваться и постоянно обновляться в VMware HCL.
3. Новая файловая система и формат On-Disk.
Virtual SAN в VMware vSphere 5.5 использовал модифицированный формат файловой системы VMFS с измененным механизмом блокировок, которая называлась VMFS-L. Теперь же в VSAN 6.0 используется файловая система VSAN FS, специально предназначенная для кластеров хранилищ.
Старый формат VMFS-L поддерживается и в новой версии, но VMware предлагает провести миграцию хранилищ, тем более что это делается без простоя сервисов.
4. Функции Proactive Rebalance.
В Virtual SAN 6.0 появилась возможность ребаланса объектов по виртуальным дискам в случае, если подключается новый узел vSphere или если диски заполнены на 80% и более. Делается это через Ruby Console.
5. VSAN Fault Domains
(группы отказа).
Теперь в VSAN можно определять домены отказа, то есть группы хостов у которых может произойти одновременный сбой (например, отказ питания на стойке), чтобы все их объекты были задублированы в других доменах:
Теперь реплики объектов происходят не на уровне хостов, а на уровне Fault Domains (в данном случае инфраструктура хранения переживет отказ одной стойки):
6. Новые функции для дисков (Serviceability Functions).
Light LED on failures – включение LED-индикатора при отказе.
Turn on disk LED manually - включение LED-индикатора вручную для диска, чтобы его можно было найти на массиве.
Marking a disk as local – если диск не обнаружился как локальный, его можно пометить вручную из GUI.
Marking a disk as SSD - теперь эта опция есть в GUI, нужна если диск автоматически не распознается как SSD.
7. Улучшения сетевого взаимодействия.
Теперь Virtual SAN 6 поддерживает конфигурации на уровне Layer 3. Кроме того, теперь доступна конфигурация с Jumbo Frames. Ну и добавлена поддержка возможностей vDS и Network IO Control (NetIOC).
8. Новый тип виртуального диска VMDK - vsanSparse.
Ранее использовались стандартные Redo-диски, но они не были приспособлены под кэширование и другие функции VSAN FS, поэтому сделали новый тип диска vsanSparse.
9. Улучшенные функции Disk/Disk Group Evacuation.
Возможность эвакуации данных с отдельного диска или группы перед тем, как вы его хотите вывести из эксплуатации физически. Ранее приходилось переводить весь хост в Maintenance Mode, чтобы было очень неудобно при поломке лишь одного диска.
10. Новое представление Resynchronization Dashboard.
Это представление показывает статус объектов, которые по тем или иным причинам находятся в состоянии ресинхронизации. Также показывается примерное время окончании синхронизации:
11. Новые службы 3rd Party File Services.
Сторонние вендоры теперь могут надстраивать свои решения над VMware Virtual SAN. Например, мы писали о таком решении совсем недавно - это NexentaConnect.
12. Полноценная поддержка командлетов PowerCLI.
Ранее интерфейс PowerCLI поддерживался неофициально, теперь же командлеты задокументированы и поддерживаются:
13. Службы мониторинга жизнедеятельности (VSAN Health Services).
Теперь для компонентов Virtual SAN доступна информация об их состоянии:
14. Storage Consumption Models.
Возможность визуализовать использование ресурсов хранения Virtual SAN 6.0 при создании или изменении VM Storage Policy.
О доступности VMware Virtual SAN 6.0 будет объявлено отдельно.
Таги: VMware, Virtual SAN, Update, VSAN, vSphere, Storage, SSD, HA
Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.
Ранее никто не воспринимал технологию Fault Tolerance всерьез, поскольку она была доступна только для виртуальных машин с одним vCPU, а такие машины, как правило, не делаются для бизнес-критичных приложений, для которых, собственно, технология Fault Tolerance и создавалась.
Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.
Какие преимущества дает VMware FT в vSphere 6.0:
Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
При отказе не разрывается TCP-соединение.
Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.
Что нового в Fault Tolerance 6.0:
Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
Возможность создания снапшотов виртуальных машин, защищенных FT.
Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.
Но по-прежнему, для Fault Tolerance остаются следующие ограничения:
На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
Обязательно потребуется адаптер 10 Gb. Его можно разделять между различными типами трафика средствами NetIOC.
Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.
Как и раньше, технология VMware HA полностью поддерживается:
Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:
Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.
Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.
Суть бага заключалась в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.
Проблема была обнаружена в начале ноября прошлого года, но только сейчас компания VMware пофиксила этот баг. Описание проблемы и решений можно найти в KB 2090639.
Zip-файлы патчей можно импортировать через VMware Update Manager:
/p>
Напомним, что для решения проблемы без патчей, надо "перещелкнуть" Changed Block Tracking на хосте ESXi (как это сделать - тут и в KB). Старые бэкапы, понятное дело, останутся невалидными. Следующий бэкап после повторного включения CBT всегда будет полным.
Интересно, что для VMware vSphere 4.x никаких патчей на эту тему выпущено не было (Currently, there is no resolution for ESXi 4.x.).
Отметим также, что компания Veeam уже давно выпустила решение этой проблемы. Пользователям Veeam Backup and Replication 8 вообще ничего делать не нужно - там эта проблема уже решена.
Как вы знаете, после запуска виртуальной машины на платформе VMware vSphere, в папке с машиной создается файл *.vswp, который предназначен для свопирования памяти ВМ в критической ситуации. Если у машины проявляется нехватка памяти на хосте VMware ESXi, и она не получает ее через механизм Memory Ballooning, то страницы памяти начинают сбрасываться в этот vswp-файл. Это самая плохая ситуация, так как структурная организация этого файла и то, как понимает своп операционная система, две большие разницы, а значит скорость работы существенно замедляется не только из-за того, что работа идет с диском вместо RAM, но еще и уходит время на поиск нужных страниц.
Соответственно, если у машины 4 ГБ оперативной памяти, то размер vswp-файла также 4 ГБ:
Если мы меняем Memory Reservation для виртуальной машины, то ее файл подкачки уменьшается на величину этого резерва - так как физическая память закрепляется за машиной и не возникнет условий, когда эту часть потребуется свопировать.
Но если сделать Memory Reservation для работающей ВМ (в данном случае 2 ГБ), то размер файла подкачки останется прежним:
Для того, чтобы vswp-файл уменьшился на величину Memory Reservation, надо перезагрузить ВМ - тогда он станет размером 2 ГБ:
Напомним, что у выключенной машины vswp-файла нет.
Но что если у включенной машины убрать (или изменить) Memory Reservation? Все просто - он автоматически увеличится до размера незарезервированной памяти ВМ. Убираем резерв в 2 ГБ и файл вырастает до 4 ГБ:
Ну и напомним формулу:
Swap (.vswp) file size = VM Configured Memory – VM reserved memory
Многие из вас, наверняка, знакомы с инициативой CoreOS (форк Chrome OS) - операционной системой на базе Linux, которая представляет собой пустую "коробку" для развертывания в ней предустановленных контейнеризованных приложений (на базе механизма Docker) и больше ничего лишнего. То есть там присутствуют только необходимые для запуска этих приложений средства.
В инициативе CoreOS принимают участие такие компании как Google, Facebook и Twitter. VMware также работает с командой CoreOS, чтобы эта система работала и поддерживалась в качестве гостевой ОС в VMware vSphere, а также обеспечивалась работоспособность пакета open-vm-tools (это аналог VMware Tools, но с открытым кодом и с меньшими возможностями).
На днях компания VMware объявила о доступности сборок CoreOS 494 и 522 для платформы VMware vSphere (как технологическое превью). Соответственно, в VMware ждут от пользователей фидбэк по результатам тестирования.
Для установки можно использовать стандартный ISO-образ или уже готовый VMDK-диск. В дальнейшем CoreOS будет поставляться как готовый виртуальный модуль (Virtual Appliance) в формате OVA. Например, в бета-версии сборки 577 OVA уже есть.
Инструкции по развертыванию CoreOS на VMware vSphere приведены в KB 2104303. Процесс пока еще не очень тривиален, но команда проекта работает над его упрощением. Сама же VMware работает над интеграцией проекта CoreOS в свое публичное облако VMware vCloud Air.
На многим из вас известном сайте VMware Labs появилось интересное мобильное приложение для смартфонов на базе Android - vMaxGuide. Оно позволяет посмотреть информацию о максимальных конфигурациях различных компонентов виртуальной инфраструктуры VMware vSphere.
На данный момент vMaxGuide предоставляет информацию о максимумах для следующих платформ:
VMware vSphere 5.5
VMware vSphere 5.1
VMware vSphere 5.0
Также в сравнениях участвуют различные версии виртуального аппаратного обеспечения (Virtual Hardware). Там где максимумы могут быть достигнуты только при определенных условиях, соответствующие пункты помечены символом "*".
Инсталляция и использование vMaxGuide:
Кстати, эта штучка может быть хорошей шпаргалкой на экзамене по VMware VCP!)
Осенью мы писали о том, что компания VMware планирует отключить технологию Transparent Page Sharing (TPS) в новых релизах платформы виртуализации VMware vSphere. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится только ссылка на нее).
Технологию TPS было решено прекратить использовать по двум причинам:
Использование в современных ОС больших страниц памяти (large memory pages) размером в 2 МБ делает намного менее вероятным появление дубликатов.
Использование одной копии страницы памяти несколькими ВМ создает потенциальные проблемы безопасности.
На данный момент статус отключенности TPS по умолчанию на хостах VMware ESXi таков:
В ESXi 5.5 U2d, запланированном на первый квартал 2015 года, TPS будет отключен.
В ESXi 5.1 U3, выпущенном 4 декабря 2014 года, TPS уже отключен.
В ESXi 5.0 U3d, запланированном на первый квартал 2015 года, TPS будет отключен.
Однако не стоит сбрасывать TPS со счетов - возможно, если вы используете старые ОС (Windows 2003) и инфраструктуру VDI на базе старых клиентских ОС, TPS сможет сэкономить вам какое-то количество памяти (если безопасность TPS вас не особенно заботит). Ну и напомним, что TPS отключена только для межмашинного взаимодействия и продолжает работать для внутримашинного.
Для этого в VMware сделали скрипт Host Memory Assessment Tool.ps1, который показывает количество памяти на хостах, которую можно сэкономить с помощью TPS.
Вот что он делает:
Соединяется с vCenter и определяет хосты ESXi
Позволяет включить SSH на хостах
Генерирует отчет об обследовании на экономию по TPS
Можно экспортировать результаты в CSV
Можно снова включить SSH, если нужно
Пока скрипт позволяет указать только одну пару логин-пароль на хостах ESXi, но надеемся это будет исправлено в следующих версиях.
Здесь вот какие значения в колонках:
Total Host Memory – объем физической памяти хоста (доступной vmkernel).
Host Mem Saved via TPS – объем памяти, которая сэкономлена TPS.
Host Mem Saved via TPS Zero Pages – объем памяти, которая экономится на нулевых страницах. Фактически такая экономия не актуальна для большинства случаев, так как сэкономленные нули означают, что недостатка ресурсов не наблюдается.
Potential Host Mem Savings Lost – а вот эта экономия уже на реально используемых страницах. Объем, указанный тут, показывает сколько можно потерять, отключив TPS на хосте.
Host Free Mem – объем свободной оперативной памяти (по данным vmkernel). Если свободной памяти меньше, чем значение в предыдущей колонке, то при отключении TPS будет своппинг.
Вот такая штука, можно проводить эксперименты (особенно полезно это будет для крупной инфраструктуры). Скрипт безопасен для памяти хостов, так как использует режим доступа к памяти только для чтения.
После запуска скрипта вам может потребоваться отключить или включить Transparent Page Sharing на хосте ESXi. В этом случае вам пригодится KB 2097593.
Как знают многие администраторы VMware vSphere, есть такое удобное средство vSphere Management Assistant (vMA), которое представляет собой виртуальный модуль (готовую виртуальную машину), средствами которой очень удобно управлять скриптами, исполняемыми на нескольких хостах VMware ESXi через интерфейс ESXCLI или Perl.
При выполнении различных сценариев на Linux-машине vMA иногда требуется создать задачу планировщика (крон-таску), чтобы запустить скрипт в назначенное время. Ниже мы опишем, как это нужно делать.
1. Чтобы запускать скрипты без аутентификации, нужно добавить хосты ESXi в vi-fastpass. Вы можете добавить только хосты ESXi, либо хост vCenter Server (или всех их). Используйте команду vifp addserver в интерактивном режиме (конфигурация сохраняется при перезагрузках):
4. Если крон-таска упадет, то вывод ошибок будет направляться сюда:
/var/mail/vi-admin
Вывод ошибки может быть таким:
Can’t load ‘/usr/lib/perl5/site_perl/5.10.0/libvmatargetlib_perl.so’ for module vmatargetlib_perl: libtypes.so: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/DynaLoader.pm line 203.
at /usr/lib/perl5/site_perl/5.10.0/VMware/VmaTargetLib.pm line 10
Compilation failed in require at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
Compilation failed in require at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.
BEGIN failed–compilation aborted at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.
Это значит вы некорректно добавили путь к библиотеке (/opt/vmware/vma/lib64:/opt/vmware/vma/lib).
Если же вы получаете вот такую ошибку:
“Server version unavailable at ‘https://[host]:443/sdk/vimService.wsdl’ at /usr/lib/perl5/5.10.0/VMware/VICommon.pm line 545.”
Это из-за непрошедшей SSL-аутентификации. Если у вас нет валидных SSL-сертификатов, отключите авторизацию через SSL в вашем скрипте:
В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.
Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.
К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.
Тут основная рекомендация - держать машины с ролями MBX / MSRна одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).
В этой части цикла описываются рекомендуемые настройки механизма VMware HA.
В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.
Данный вебинар будет интересен любому, кто когда-либо задумывался о защите виртуальной инфраструктуры VMware vSphere.
Вебинар пройдет: 24 декабря в 11:00 по московскому времени. Проводит: Иван Колегов, системный аналитик компании "Код Безопасности".
Мероприятие будет интересно руководителям ИБ-служб, а также специалистам, обеспечивающим безопасность дата-центров и защиту виртуальных инфраструктур.
В ходе вебинара вы узнаете:
об архитектуре vGate и его компонентах;
о правилах лицензирования продукта;
о том, как быстро установить vGate и правильно его настроить;
о том, как с его помощью обеспечить безопасность средств управления платформ виртуализации и виртуальных машин.
Продолжительность вебинара – 60 минут.
По окончании вебинара вы сможете задать докладчику вопросы в режиме чата и оставить заявки на получение демоверсии продукта и дополнительных материалов.
Для тех из вас, кто по каким-либо причинам еще не обновился на vSphere 5.5, полезная новость - вышло обновление VMware vSphere 5.1 Update 3 (ESXi и vCenter), которое уже доступно для загрузки. Новых возможностей не появилось, зато была добавлена поддержка новых гостевых ОС и исправлены некоторые значимые баги.
Итак, что нового в ESXi и vCenter 5.1 U3:
Поддержка новых БД vCenter Server - теперь можно использовать
Oracle 12c и
Microsoft SQL Server 2014
Поддержка новых браузеров для Web Client 5.1 Update 3. Теперь поддерживаются:
Internet Explorer 8 / 9 / 10/ 11
Firefox 31 / 32 / 33
Google Chrome 36 / 37
Поддержка новых гостевых ОС. Полный список поддерживаемых ОС можно посмотреть тут.
Компания VMware выпустила еще один интересный документ, описывающий референсную архитектуру программно-определяемого датацентра (SDDC) - "Creating a VMware Software-Defined Data Center".
В данном документе на 29 страницах приводится пример создания корпоративной инфраструктуры на базе следующих продуктов:
Описание программных компонентов для построения SDDC-инфраструктуры
Обзор референсной архитектуры
Информация об оборудовании и аппаратных компонентах
Детальная информация о компонентах Software-Defined Data Center
Высокоуровневая конфигурация инфраструктуры SDDC
В рассматриваемой архитектуре есть три основных модуля:
Management Cluster - основной кластер управления и мониторинга, в котором работают такие средства как vCenter, Log Insight и прочие. Состоит минимум из трех хост-серверов ESXi.
Edge Cluster - отдельный кластер для управления сетевым взаимодействием. Он упрощает конфигурацию физической сети передачи данных путем создания абстракции физического сетевого стека в ИТ-инфраструктуре. Также содержит минимально 3 хоста.
Payload Cluster - "рабочая лошадка" виртуальной инфраструктуры, кластер, где крутятся рабочие нагрузки. Может масштабироваться "подами" (pods) по мере роста потребностей предприятия.
В целом документ весьма интересный, так как в комплексе затрагивает управляющие компоненты виртуальной инфраструктуры и показывает работу средств управления большой виртуальной средой, а также то, каким образом эти средства решают возникающие в такой инфраструктуре проблемы.
Ниже мы приведем еще один аргумент в пользу того, чтобы не создавать снапшоты виртуальных машин на постоянной основе (во временном их использовании нет ничего плохого).
Итак, в одной из статей мы писали про расширенную настройку VMFS Heap Size (размер кучи), которая косвенно определяет максимально доступный объем хранилищ на хосте.
Также мы писали о том, что параметр VMFS3.MaxHeapSizeMB еще в VMware vSphere 5.1 был увеличен до 640 МБ.
Однако есть и куча для механизма "Copy-on-Write" (COW), которая определяется расширенной настройкой COW.COWMaxHeapSizeMB - она ограничивает число одновременно запущенных на хосте виртуальных машин. Механизм COW работает на хосте, когда у машины есть снапшоты (дельта-диски).
По умолчанию это значение равно 192 МБ, но может быть увеличено до 256 МБ:
Также этот параметр можно узнать из командной строки:
~ # esxcfg-advcfg -g /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 192
И установить его в максимальное значение:
~ # esxcfg-advcfg -s 256 /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 256MB
Давайте посмотрим, как расходуется пространство этой кучи на хосте, в зависимости от параметров виртуальных машин на нем. Вот тут есть такая интересная формула:
X - это максимальное число запущенных виртуальных машин на хосте,
COW_HEAP_SIZE - размер кучи в байтах,
B - размер виртуального диска в байтах,
2 * 1048576 - это GDE Coverage (хз, что такое),
4 - это число байт на Root Entry,
S - число снапшотов каждого из виртуальных дисков,
Y - число дисков у машин.
Возьмем для примера машину с 5 дисками размером в 80 ГБ по 6 снапшотов у каждого при максимальном размере кучи в 256 МБ. Получим, что таких машин может быть запущено на хосте:
Это примерно около 40 машин (всего лишь) - при максимально доступном размере кучи на VMware ESXi. Понятно дело, что мало где можно найти машины с 5 дисками, у каждого из которых по 6 снапшотов, но я видел подобные конфигурации пару раз.
Нетрудно понять, как в этой формуле влияют снапшоты на максимальное число запущенных виртуальных машин. Поэтому повторим еще раз: постоянные снапшоты - зло.
Надо сказать, что компания Код Безопасности обеспечивает исполнение этого приказа во всех аспектах, но нас больше интересует виртуальная среда. Итак, скачиваем вот этот документ с сайта Кода Безопасности.
Открываем его на первой вкладке и видим необходимые нам категории в столбце "vGate 2.5":
Очень удобно, что все требования разбиты по категориям, а также указано сразу какой уровень защищенности ПДн обеспечивает то или иное средство. Вот какие конкретно требования ФСТЭК по защите персональных данных позволяет выполнить vGate R2:
Идентификация и аутентификация пользователей, являющихся работниками оператора
Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
Управление идентификаторами, в том числе cоздание, присвоение, уничтожение идентификаторов
Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
Защита обратной связи при вводе аутентификационной информации
Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей, в том числе внешних пользователей
Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами
Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
Ограничение неуспешных попыток входа в информационную систему (доступа к информационной системе)
Разрешение (запрет) действий пользователей, разрешенных до идентификации и аутентификации
Поддержка и сохранение атрибутов безопасности (меток безопасности), связанных с информацией в процессе ее хранения и обработки
Обеспечение доверенной загрузки средств вычислительной техники
Управление запуском (обращениями) компонентов программного обеспечения, в том числе определение запускаемых компонентов, настройка параметров запуска компонентов, контроль за запуском компонентов программного обеспечения
Определение событий безопасности, подлежащих регистрации, и сроков их хранения
Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
Защита информации о событиях безопасности
Контроль работоспособности, параметров настройки и правильности функционирования программного обеспечения и средств защиты информации
Контроль правил генерации и смены паролей пользователей, заведения и удаления учетных записей пользователей, реализации правил разграничения доступа, полномочий пользователей в информационной системе
Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
Контроль целостности персональных данных, содержащихся в базах данных информационной системы
Обеспечение возможности восстановления программного обеспечения, включая программное обеспечение средств защиты информации, при возникновении нештатных ситуаций
Резервирование технических средств, программного обеспечения, каналов передачи информации, средств обеспечения функционирования информационной системы
Идентификация и аутентификация субъектов доступа и объектов доступа в виртуальной инфраструктуре, в том числе администраторов управления средствами виртуализации
Управление доступом субъектов доступа к объектам доступа в виртуальной инфраструктуре, в том числе внутри виртуальных машин
Регистрация событий безопасности в виртуальной инфраструктуре
Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры
Доверенная загрузка серверов виртуализации, виртуальной машины (контейнера), серверов управления виртуализацией
Управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных
Контроль целостности виртуальной инфраструктуры и ее конфигураций
Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей
Обеспечение доверенных канала, маршрута между администратором, пользователем и средствами защиты информации (функциями безопасности средств защиты информации)
Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
Изоляция процессов (выполнение программ) в выделенной области памяти
Да да, все это умеет делать vGate R2. Для того, чтобы узнать о том, как именно он это делает, читайте наши статьи тут и тут.
Кстати, этот эксель-док очень интересен с точки зрения комплексной защиты персональных данных, обрабатываемых в ИТ-инфраструктуре. Посмотрите различные продукты, пощелкайте по вкладкам - там много интересного.
Демо-версию vGate для Hyper-V можно бесплатно скачать по этой ссылке, а для VMware vSphere - по этой.
Как многие из вас знают, у компании VMware есть бесплатный продукт VMware vSphere Hypervisor, который в народе называется VMware ESXi Free. Многие начинающие администраторы, услышав, что ESXi бесплатен, устанавливают его, но забывают накатить лицензию, которую надо скачивать с портала My VMware. Без этого бесплатный VMware ESXi будет работать в режиме пробной версии 60 дней...
Многие администраторы устанавливают VMware Tools с помощью vSphere Client, который предоставляет идущую в дистрибутиве версию этого пакета. Однако не все знают, что VMware Tools можно скачать по прямой ссылке из репозитория VMware, затем положить exe-файл на файловый сервер (если у вас гостевая ОС Windows) и запускать на всех виртуальных машинах.
Последняя версия тулзов всегда находится по этой ссылке:
Но эти пакеты доступны только для следующих версий гостевых ОС:
Community ENTerprise Operating System (CentOS) - версии с 4.0 по 6.x
Red Hat Enterprise Linux версии с 3.0 по 6.x
SUSE Linux Enterprise Server версии 9 по 11
SUSE Linux Enterprise Desktop версии 10 по 11
Ubuntu Linux версии с 8.04 по 12.04
Надо отметить, что доступные в репозитории пакеты содержат компоненты VMware Tools, начиная еще с версий ESX 3.5. Но с версии vSphere 4.1 все они стали обратно совместимы - вы можете скачать последнее обновление VMware Tools и накатить его на любую версию vSphere 4.x или 5.x.
Кроме того, если в списке остутствуют необходимые ОС Linux, то можно воспользоваться пакетом Open VM Tools, которые являются открытой версией VMware Tools и рекомендованы к распространению вендорами платформ. Например, вот тут указано, как нужно ставить Open VM Tools в гостевых ОС RHEL 7.
Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.
При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).
Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:
Заходим на хост по SSH и переходим в папку с утилитами HP:
cd /opt/hp/tools
Копируем настройки HP iLO в файл XML:
./hponcfg -w ilo.xml
Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.
Копируем iLO.xml к себе локально:
Открываем его в текстовом редакторе и правим секции, помеченные красным:
<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/> <IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>
Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:
./hponcfg -f ILO.xml
Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.
Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.
Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.
Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:
Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.
Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.
То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.
Многие пользователи в целях безопасности хотят отключить использование USB-портов на хостах VMware ESXi - а то кто-нибудь зайдет в серверную комнату и утащит данные на диске.
К сожалению, на текущих версиях платформы VMware vSphere сделать этого нельзя. Можно, конечно, отключить USB Arbitrator service следующей командой (как написано вот тут):
/etc/init.d/usbarbitrator stop
Но это лишь отключит проброс USB-устройств в виртуальные машины, при этом само устройство (например, /dev/usb0101) отключено не будет. Поэтому, тут остается два решения:
Отключить USB-устройства в BIOS - но это поддерживают не все производители железа.
Мониторить использование локальных USB-устройств и слать алерты менеджеру по ИБ.
Второй вариант можно реализовать с помощью продукта VMware vRealize Log Insight, который позволяет мониторить логи хостов ESXi и слать по ним алерты при их появлении и повторении. Вот, например, в выводе этого лога мы видим, что кто-то подключал USB-девайс к хосту:
Сопоставив время этих событий и время посещения конкретными людьми датацентра, мы поймем, кто пытался или сделал что-то нехорошее. Решение, конечно, не ахти, но какое уж есть.
На сайте компании VMware есть полезная утилита vSphere Replication Calculator, которая позволяет рассчитать целевые параметры репликации в зависимости от следующих факторов:
Наличие у вас Network-based storage
Число виртуальных машин и объем виртуальных дисков - как следствие размер реплицируемых данных (Size of dataset)
Интенсивность изменения данных (Data change rate)
Требования к контрольной точке восстановления (Recovery point objective, RPO)
Имеющийся канал на резервную площадку (Link speed)
В качестве результата расчетов можно выбрать одно из трех представлений (все зависит от значения поля "Are you trying to solve..."):
Необходимая минимальная пропускная способность сети на резервную площадку (recommended minimum throughput) с приемлемой latency (настраивается как входной параметр).
Рекомендуемое минимальное время RPO в качестве политики, выражающей требования к контрольной точке восстановления.
Максимальное число реплицируемых виртуальных машин при условии заданного объема изменяющихся данных.
Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.
Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).
Далее заходим на свой хост ESXi по SSH и выполняем команду:
esxcli vm process list
Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.
Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):
esxcli vm process kill -t force -w WorldID
Выглядит это примерно вот так:
Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.
Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:
vim-cmd vmsvc/getallvms
Если помните часть имени ВМ, можно искать с помощью grep:
vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>
Найдя VMID, проверяем дополнительно, что она выключена:
vim-cmd vmsvc/power.getstate <vmid>
Теперь включаем виртуальную машину:
vim-cmd vmsvc/power.on <vmid>
Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.
Как стало известно из VMware KB 2090639, в гипервизоре VMware vSphere 4.x и всех более поздних версий (включая vSphere 5.5) есть серьезный баг - оказывается, при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.
Напомним, что Changed Block Tracking - это техника, которая работает на уровне стека работы с хранилищами в модуле VMkernel и позволяет сторонним продуктам для резервного копирования вернуть список изменившихся блоков с момента последнего бэкапа. Технику CBT используют практически все решения для резервного копирования виртуальных машин, в частности Veeam Backup and Replication.
Сама же ошибка в VMware vSphere связана с тем, что функция QueryChangedDiskAreas, возвращающая информацию об изменившихся дисковых секторах, может выдавать некорректное или вообще пустое значение. Таким образом, если вы восстановите инкрементальный бэкап такой машины, то он работать не будет.
Еще раз отметим, что риску подвержены только те виртуальные машины, размер виртуальных дисков был увеличен до величины строго большей 128 ГБ (а также 256, 512 и т.п. - то есть "перешагнул" границу). Иными словами, если вы со 100 ГБ увеличили диск до 120 ГБ - ошибки не будет, а вот если со 120 ГБ до 130 ГБ - ошибка уже появится.
На данный момент исправления для этой проблемы, потенциально затрагивающей практически всех пользователей VMware vSphere (так как баг есть и в 4.x, и в 5.x), не существует. В качестве костыля можно отключить CBT на всех виртуальных машинах и включить его снова - тогда баг должен уйти.
Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:
Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).
Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.
Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.
Нажимаем Add Capacity:
Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):
Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):
Настройка Virtual Flash Host Swap
Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.
Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":
Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":
После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).
Настройка VMware Flash Read Cache (vFRC)
Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.
Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.
Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:
Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.
По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):
Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.
RSS
